Data certification method and apparatus

ABSTRACT

An apparatus and method for signing electronic data with a digital signature in which a central server comprises a signature server ( 110 ) and an authentication server ( 120 ). The signature server ( 110 ) securely stores the private cryptographic keys of a number of users ( 102 ). The user ( 102 ) contacts the central server using a workstation ( 101 ) through a secure channel which is setup for the purpose. The user ( 102 ) supplies a password or other token ( 190 ), based on information previously supplied to the user by the authentication server ( 120 ) through a separate authentication channel. The authentication server provides the signature server with a derived version of the same information through a permanent secure channel between the servers, which is compared with the one supplied by the user ( 102 ). If they match, data received from the user ( 102 ) is signed with the user&#39;s private key.

The present invention relates to the certification of data sent over anetwork, more specifically over an insecure network such as the Internetby cryptographic means,

Whenever information is transmitted across an insecure network, there isthe possibility that this may be intercepted and interfered with in someway. Therefore, many activities carried out using such a network toconnect the parties involved in the activity require each party toconfirm the identity of the other party(s). This is particularly thecase with activities conducted over the Internet.

One way of meeting the above requirement is to use a digital signature.The origin of data sent across an insecure network can be authenticatedusing such a digital signature.

Such a signature fulfils the roles of a traditional signature: toprovide authentication of origin, and may also have legal significance.It is therefore important to ensure that it is difficult, if notimpossible, to sign an electronic document fraudulently, in order tosuggest an incorrect point of origin.

A generally accepted—and the only known—way of achieving this is to usecryptography. In particular, a form of asymmetric cryptography called apublic key scheme is used A public key scheme employs two different butmathematically related “keys”. Such asymmetric keys work by using a socalled “one way” algorithm. Such an algorithm can be used to produce aso-called digital signature with one key and verify this with the otherkey, but it is very time-consuming and in fact practically infeasible,with the right choice of key size, to use the verifying key to generatethe signature. Currently it is a very simple matter to use theverification key to verify the signature and hence the integrity andorigin of the message, and this is how each key pair is normally used.These public key schemes may either be based on so called one-wayfunctions, where the verification process involves checking amathematical equation (e.g. ElGamal, elliptic curves, etc. see Menezes,A, Oorschot, P. van, and Vanstone, S., Handbook of Applied Cryptography,CRC, 1996, the contents of which are incorporated herein by reference)or on encryption-decryption functions (e.g. RSA, see Rivest, R. L.,Shamir, A. and Adleman, L, A method for Obtaining Digital Signatures ofPublic Key Cryptosystems, Communications of the ACM, 21 (2), 1978:120-126, the contents of which are incorporated herein by reference).The latter differs from symmetric encryption, where the same key is usedto both encrypt and decrypt a message. One of the advantages of suchasymmetric methods is that even if a third party is in possession of thekey used to verify the message they cannot produce the signature withoutthe other key. If an encryption-decryption scheme is used, theencryption key is the verifying key and the decryption key is thesigning key.

The most widely used public scheme, RSA, makes use of two very largeprime numbers, and the fact that, at the time of writing, it takes avery long time to factor the product of these two primes back into thetwo original numbers. With sufficiently large numbers, RSA can thereforebe highly resistant to signature falsification. Generally, one of thekeys is the product n of the two prime factors pa and q and a so-calledpublic exponent e, and the other is a number derived from the pair ofprimes and e using modular arithmetic. The public exponent e must bechosen as mutually prime to p−1 and q−1, and a secret exponent d maythen be derived e.g. as the smallest positive integer satisfyinged−x(p−1)(q−1)=1 for some x using Euclid's algorithm repeatedly. Furtherinformation on this may be found in Menezes et al, mentioned above.

Because knowledge of the key used for verification does not enablesigning, it is possible to broadcast this key (the so called “publickey”) as widely as possible, to as many people as possible, typically byproviding a so-called Public Key Infrastructure (PKI, see CCITT(Consultative Comm. on Intern. Telegraphy and Telephony), RecommendationX.509: The Directory—Authentication Framework, 1994, and Public KeyInfrastructure: The PKIX Reference Implementation, Internet TaskEngineering Force, both of which are incorporated herein by reference)so that anyone can make use of it.

If a particular public key can be used to verify a message, this showsthat the originator of the message must have been the user holding theprivate key. It is therefore possible to indicate the origin of aparticular message by making use of public key schemes.

However, this therefore requires that there is some scheme in place tobind the identity of the user to a particular public key pair

For example, the holder could simply announce that he owns thepublic/private key pair to the world. However, the recipient of thesigned document would then only have the word of the holder as to hisidentity and that the holder is the owner, and that the key has not beencompromised. In this case, the recipient of the message cannot verifythat the sender of the message is being truthful about their identity orownership status, only that the message has come from someone claiming aparticular identity and claiming to be the owner of the key pair.

Because of the above problems of verification of the identity and statusof PKI key owners, third parties called Certification Authorities (CAs)have evolved to certify that a particular user is who they claim to be.The user must supply certain credentials to the CA and his public key,and the CA in return issues a so-called certificate, which is nothingbut a signature generated by the CA on a message in a chosen format,such as X.509v3, consisting of the user's credentials and his publickey. In addition, the CA must make a Directory available, from which thestatus of any user key can be communicated to any other user at anytime, either by use of so-called revocation lists, or by online inquiry.Furthermore, the CA issues a Certificate Policy Statement, which statesthe rules for the users of the system, including the method by which theusers have been identified. For details see CCITT, and Public KeyInfrastructure: The PKIX Reference Implementation, mentioned above.

A digital certificate, comprising a public key/private key pair hasadditional advantages over a traditional signature solution withoutcertificates in that it may have a limited operational period and mayalso be suspended or revoked, should the private key of the user becompromised, for example by being made available to a third party. Inorder for the signature to be of any use, it must preferably berepresented in a standardised format, such as Public Key Crypto Standard(PKCS#1) signatures, formatted according to CMS (the CryptographicMessage Syntax) (PKCS#7, for further information on which see PKCS #1,7,RSA Cryptography Standard, RSA Laboratories, 2001, the contents of whichare incorporated herein by reference).

As can be seen from above, it is vitally important that the private keyof a signature be kept secure at all times, otherwise its value isremoved, as its value lies in the fact that it certifies the identity ofthe author of a message by showing that the message originated from theowner of a particular key pair. This is only the case where the privatekey has not been compromised. Therefore, steps must be taken to maintainthe security of the private key.

One established approach to the protection of the private key of a keypair used for digital signatures is to use software solutions and thenstore it on the owner's workstation or a floppy disk protected by apincode or passphrase controlled by the owner. However, it is generallyagreed that such a software-only solution is not sufficiently secure forhigh value transactions, unless the workstation is extraordinarily wellprotected. This is because it will typically be possible to recover theprivate key using an exhaustive search for the password on theworkstation, and in any case, it is difficult to protect the private keyfrom so-called “Trojan horse” attacks. Here a malicious programme, atype of virus, is installed by an intruder, e.g. via an e-mail whichcontains an executable file, and this programme secretly copies theprivate key of the user when it is being used in the signature process,or it secretly copies the passphrase used to protect the private key.Measures can be introduced which make such attacks more difficult, buteven so, they are still not easily prevented. For security andapplicability reasons the physical protection offered by smartcards,which in addition provide a mobile solution, is attractive. Thedisadvantage of his method is that it requires smartcard readers, whichare still not widely available.

An alternative, which for a long time was considered very attractive, isinstead to store the private key on a smartcard (chipcard). But thisrequires that the workstation used for the application must have asmartcard reader attached. As workstations very rarely have such areader built-in as standard, and as there is no single dominatingstandard for communicating with the chipcard, the only possibility is toattach an extend unit and install a driver on the workstation, which isboth time consuming and expensive.

Identification and security are major issues for solutions that allowthe user to generate a digital signature. It is therefore an object ofthis invention to remove or ameliorate at least one of the problemsassociated with the prior art. In particular, an object is to reach ahigh security level, while at the same time give a flexible solution tothe problem.

In addition, private keys stored on a workstation may appear “in theclear”, that is in a non-encrypted form, in the user's computer's cacheor printer cache or spooler, or otherwise on an Internet ServiceProvider (ISP) cache, even if deleted from the user's computer. In fact,even deleted items can be recovered from a computer using specialisedtechniques to recover data from hard disk drives etc. Indeed, wheneverthe private key is used for signature generation, it has to be providedin unprotected form.

Other solutions to the security problem allow the user to download theirprivate key from a central server and generate the signature on theworkstation in software. This yields the mobility but it is stillvulnerable to attacks if the workstation is insecure, which it typicallyis unless there are restrictions on which workstations can be used todownload the private key.

In an embodiment of the present invention, the private key of the useris stored centrally on a certifying apparatus consisting of one of moreservers—not necessarily all at the same physical site. The servers aretamper resistant, typically employing a Hardware Security Module (HSM)such as an IBM 4758 with a limited command set available. One of theseservers, called the signature server, contains the private keys ofdifferent users, initiated in such a way that only the rightful ownercan initiate signature generation with his own private key.

According to the invention there is provided a method of certifying datasupplied by a user by generating a digital signature or similar on thisdata at his control by means of his private key, the method comprisingreceiving the data to be certified at a certifying apparatus from asource device, certifying the data at the certifying apparatus with oneor more elements of information secure to the certifying apparatus, saidelements being unique to the user and outputting the data so certifiedfrom the certifying apparatus, for passing to a recipient device,wherein the elements of secure information certify that the supplier ofthe data is the user.

The above method provides advantages of reduced cost of administrationof the certifying apparatus, increased ease of use for the users, andincreased security, as the information unique to the user never leavesthe signature server of the certifying apparatus, whether in encryptedform or not. This allows the user to use multiple workstations withoutcarrying their private key to each workstation. Therefore, only a breachof the signature server can result in the private keys being madeavailable outside the signature server, which consequently must beprevented using tamper resistant hardware designed for the purpose, suchas the IBM 4758.

In more advanced scenarios, the private key could actually bedistributed between any number N of servers using what is )mown as“secret sharing” in such as way that they each have a component of thekey by which they can calculate an input for the generation of thesignature, which is supplied back to the source device, where the filldigital signature is then calculated from K inputs where K is somenumber between 2 and N. The advantage of this is that at least K serverswould have to be compromised before an attacker could calculate theprivate key.

The certifying apparatus may include anything which is century based,and accessible from one or more source devices. Preferably, thecertifying apparatus comprises a signature server. Preferably, thecertifying apparatus also comprises an authentication server.Preferably, the certifying apparatus is accessible from many sourcedevices.

The source device may typically be a workstation, but may also be aninteractive television, or an Automated Teller Machine for supplyingcash or other information from a central certifying apparatus. Thesource device will have all software required to communicate effectivelywith the certifying apparatus, but this could be supplied or downloadedto the source device for the required duration of interaction only. Thesource device allows communication with the certifying apparatus.

Preferably, the unique element or elements comprise the private key of apublic key/private key pair specific to the user. The unique element orelements may generate a digital signature specific to the user, on datasupplied by the user. Such PKI keys and digital signatures provide highsecurity for the reasons given above, in that they are very hard anddecrypt fraudulently.

The recipient device may be the same as the source device, or,alternatively, it may be a third party device. The latter allows thewhole message, or only a derived part, (preferably a hash value) of amessage to be certified to be passed on to the required party withoutnecessarily returning the certified message to the source device aftercertification.

The third party device may be any appropriate device for receiving thecertified data, other than the source device, such as a separateworkstation, or a network of computers. For example, the third partydevice could be a gateway for a Local Area Network (LAN). Alternatively,the certifying apparatus and third party device could be within a singleLAN, or comprise a Wide Area Network (WAN).

In a further aspect of the invention there is provided a method ofcertifying electronic data supplied by a user as originating from thatuser, the method comprising establishing a secure connection between asource device and a certifying apparatus, sending the data from thesource device to be received by the certifying apparatus, and receivinga version of the data from the certifying apparatus certified asoriginating from the user using information unique to the user bycryptographic techniques.

Preferably, the step of incorporating the certified version of the datainto further data to be sent to a third patty device is included

Preferably, the certifying apparatus holds information unique to theuser to carry out the certification.

Preferably, the unique information is the private key of a publickey/private key pair specific to the user. Also, preferably, the uniqueinformation is a digital signature specific to the user. Preferably, thedata to be certified is a hash value of a message. This gives theadvantage that the whole message need not be sent to the signatureserver to be signed, so reducing the network traffic between the sourcedevice and signature server.

Preferably, the source device and certifying apparatus establish anauthenticated connection between them before and during transfer of thedata to be certified. Additionally, the connection may be encrypted.This reduces the possibility that the connection will be intercepted orinterfered with.

The source device may supply one or several tokens to the certifyingapparatus for authentication. Preferably, one of the tokens is suppliedto the user or source device by the certifying apparatus via analternate channel to the authenticated connection. This also increasessecurity significantly, by requiring two channels to be intercepted tofully access the data.

The alternate channel could be a mobile telephone network channel. It isparticularly preferred to use Short Message Service messages to conveythe token.

The token may be a fixed password in the most simple solution. In apreferred solution, the token is a one-time password, which has beencommunicated through an authenticated channel such as a mobile phone, oris calculated dynamically by means of a physical token which shares akey with the certifying apparatus. Such solutions are generallyavailable on the market, and examples are given below.

Preferably, the token is unique to each transaction, a transaction beingthe process of signing data, supplied by the source device, by thecertifying device and supplying the signed data to a recipient device.The token may be stored on a portable device.

Preferably, more than one type of token may authenticate the user orsource device. For example, a fixed password may be used in addition toa one-time password generated by a physical token or sent to the user'smobile phone. The independence of these tokens makes it very difficultfor an attacker to compromise both simultaneously. Thus such schemes aresaid to provide ‘strong’ authentication of the user, and may be employedto achieve a higher level of security than that obtained by use of asingle authentication token alone.

A further preferable feature is that the method operates with one levelof security reached by authenticating the user regardless of the sourcedevice, and another, higher, level of security reached by authenticatingthe user and the source device. Preferably, the certifying apparatuscertifies the data with different unique elements, dependent upon thetype of token used to authenticate the user or source device of securityas well as the data. Such multiple level authentication allows differentlevels of security, and trust, to be placed on connections utilisingdifferent types of token, and different levels of signature to be useddependent on the token used.

Where more than one type of token is used, perhaps simultaneously, toauthenticate the user, it may be desirable to ensure that administrationof these tokens is handled by separate independent groups ofadministrators. To this end, it is possible to configure the certifyingapparatus as a group of more than one separate servers, and to have eachserver manage one or more independent authentication tokens.

One example of this is in the case where the user's private key isdistributed using a secret sharing scheme between several servers. Analternative is for the user key to reside in a single server, known asthe signature server, and for this to operate in conjunction with one ormore other servers associated with user authentication, known asauthentication servers.

The user may establish separate connections to each server. It is alsopossible for the user to authenticate themselves using tokens managed byseparate servers without having to establish separate connections toeach server. An example of such a scheme is given in the description ofan embodiment of the invention below.

Preferably, validation data for validating the user and/or the data tobe certified must be received by the certifying apparatus before thedata can be certified

Preferably, the certifying apparatus sends a request to a remote deviceto provide the user with identification data Further, the certifyingapparatus may receive a version of the identification data (for examplea one-time password) from the remote device, and this version may becompared with further user data supplied from the user (for example aderived version of the one-tie password). Then, if the comparison issuccessful, the data to be certified is certified as originating fromthe user.

A connection may be established between the workstation of the user andthe remote device. This connection may be verified and authenticatedindependently of the connection between the workstation and thecertifying device/signature server.

According to a farther aspect of the invention, there is provided amethod for use in certification of data comprising receiving a requestfrom a remote device to supply a user with identification data,supplying said identification data to a user, and supplying a derivedversion of the identification data to the remote device.

This method provides a fierier channel for sending identification datasuch as one-time passwords to a user. The method of transferring theidentification data may be different to the method used for transferringthe request from the remote device, and the method of sending thederived version of the identification data.

According to further aspects of the invention, a computer apparatus isprovided as claimed in Claim 43 or 45. According to further aspects ofthe invention, a carrier medium is provided as claimed in Claim 44 or46.

According to a filer aspect of the present invention, there is provideda data certifying apparatus, comprising a signing device adapted tocertify data received from a remote source device as originating from auser, wherein the certifying apparatus is arranged to receive data fromthe source device, certify the data as belonging to the user, usinginformation stored in the certifying apparatus, said information beingunique to the user, and send the certified data to a recipient device.

Preferably, the recipient device is the source device. Alternatively,the recipient device may be a third party device.

Preferably, the source device and certifying apparatus are arranged toestablish an authenticated connection between them before and duringtransfer of the data to be certified. A further preferable feature isthat the connection is encrypted.

The source device may be arranged to supply a token to the certifyingapparatus for authentication. Preferably, this token is supplied to theuser or source by the authentication device via an alternate channel tothe authenticated connection. The token may be a fixed passwordAlternatively, the password may be a one time password. Again, the tokenmay be unique to the transaction.

Preferably, in the apparatus of the present invention more than one typeof token may authenticate the user and the source device.

As a further preferable feature, the data certifying apparatus may bearranged to operate with one level of security reached by authenticatingthe user regardless of the source device, and another, higher, level ofsecurity reached by authenticating the user and the source device, ifone particular source device, e.g. a trusted work station is used.Additionally, the certifying apparatus may be arranged to certify thedata with different unique elements, dependent upon the type of tokenused to authenticate the user or source device of security as well asthe data.

The certifying apparatus may also comprise instructing means for sendinga request to a remote device to instruct the remote device to sendidentification data (for example a one-time password) to the user. Thecertifying apparatus may also comprise receiving means for receivingdata derived from the identification data from the remote device.

The derived data from the remote device may be compared with comparisonmeans to further data received by the receiving means, and certifyingmeans which certify the data to be certified if the data compared at thecomparison means match.

According to a further aspect of the invention, there is provided anapparatus for use in data certification, comprising receiving means forreceiving a request from a remote device to supply a user withidentification data supplying means for supplying said identificationdata to a user and further supplying means for supplying a derivedversion of the identification data to the remote device.

Preferably, password generating means are also provided, which generatea password, for example a one-time password, although otheridentification data may also be generated Preferably, the receivingmeans and further supplying means are arranged to operate via adifferent communication method to the supplying means.

The embodiments and aspects of the invention described above are notonly to be interpreted individually nor solely in combination, but maybe combined in any way in order to provide further embodiments of theinvention. Additionally, individual features from an embodiment may becombined with other features from another embodiment so that variouscombinations of individual features from different embodiments andaspects also provide further embodiments of the invention.

Specific embodiments of the present invention will now be described,purely by way of example, with reference to the drawings, in which:

FIG. 1 shows the architecture of the connections between variouscomponents according to a first embodiment of the present invention;

FIG. 2 shows the steps involved in granting a user exclusive access totheir signature key according to the first embodiment of the invention;

FIG. 3 shows a flow diagram of a method according to a first embodimentof the invention;

FIG. 4 shows a flow diagram of a method according to a furtherembodiment of the invention; and

FIG. 5 shows a flow diagram according to a further embodiment of thepresent invention.

FIG. 1 schematically shows a system according to an embodiment of thepresent invention. It shows a user 102 operating a source device, whichin the present embodiment is a workstation 101, which is connected to acertifying device, which in the present embodiment is signature server110, via a communication line 140. The communication line 140 is notinherently secure. The workstation 101 may be any terminal at whichcommunication may be established with the signature server 110. Forexample, the workstation 101 may be an interactive television set. Therequirement is that the workstation 101 can communicate with thesignature server 110. No special software is required at the workstation101 side of the link. The signature server 110 securely stores theprivate keys of each user and may additionally log some or all relevantinformation regarding users and their activities. The signature server110 handles requests from users via the workstation 101 and may issuerequests to a CA server. The signature server 110 is ideally certifiedto an International standard, such as FIPS 140-1 level 3 or 4 (see FIPSPub 140-1, 1994. National Institute of Standards & Technology, USA, thecontents of which are incorporated herein by reference), which is agenerally accepted standard to indicate the quality of the tamperresistance features of the hardware protection of the server.

The signature server 110 receives data, which is to be verified asoriginating from the user, from the workstation 101. Verification isachieved using the private key of the user, which is stored on thesignature server 110, to encrypt data received from the workstation 101and return that data to a recipient, which may be the user or a thirdparty. Processes according to embodiments of the present invention willbe described in more detail with reference to FIGS. 3, 4 and 5 below.

The details of the hardware used in this embodiment of the inventionwill now be described. In addition to the signature server 110, in anembodiment of the present embodiment the certification apparatus alsohas a separate authentication server 120, which is enhanced by tamperresistant hardware just as the signature server 110. Alternatively, theauthentication server 120 may be remote to the signature server 110. Thesignature server 110 is connected to the authentication server 120 via astrong cryptographic link 150 (i.e. encrypted and authenticated), forexample by a shared master key, or based on public keyencryption-decryption, using standard solutions, also sometimes known asa VPN (virtual private network). This is used to establish a session keyand secure an encrypted channel between the servers using standardcryptographic techniques as is well known in the art. The key used mightdepend on the user password used for access. The secure tunnel 150 fromauthentication server 120 to signature server 110 continues into thehardware part of the signature server 110, in the sense that the keysused for this tunnel are controlled by tamper resistant hardware andnever appear in the clear outside the certifying apparatus. Theintegrity of the system does not then have to rely so much on the securearea in which the server is placed. The same applies for allcommunication to and from both the signature server 110 andauthentication server 120.

The authentication server 120 distributes one-time passwords and/orchallenges to customers through an alternate channel 151. In the presentembodiment, the alternate channel 151 employs SMS (short messageservice) messages sent via a cellular network for mobile phones forcommunicating the one-time passwords. Alternatively, the user mightpossess a handheld so-called secure token 190, a small device whichshares an individual key with the authentication server 120. Once thechallenge has been received via the workstation 101, this is keyed in bythe user on the token 190, and the response which basically is anencryption of the challenge with the key held on the token 190, is keyedin at the workstation 101 as the one-time password. The signature server110 may verify that the response is indeed an encryption of thechallenge as it receives a derived version of the one time password fromthe authentication server 120. However, many alternatives are availablesuch as Wireless Application Protocol (WAP) over a cellular network(which is a specialised version of the Internet, and which can beaccessed by WAP enabled mobile telephones), or ordinary paper mail.Alternatively, passwords may be distributed via the Internet, via anapplet, which communicates as directly as possible with a printerattached to the workstation 101 (as this limits the risk of passwordcopies remaining in their printer/spooler buffers, or on the workstation101 by means of Trojan horses which “sniff” the passwords). Examples oftypes of password that can be used in the present invention arediscussed below in any event, the exact nature of this authenticationprocess is not limited to that described, and many variations arepossible within the context of the invention.

At registration, a fixed password is forwarded in a secure way to theuser 102—which at any point in time he may change—so that each user 102may be authenticated in a connection between a workstation 101 andsignature server 110 as part of the user authentication process. In thepresent embodiment, in addition an on-line, one-time password isdistributed via an SMS message from the authentication server 120 to theuser's mobile phone (not shown). Such an on-line one-time password canhave an extremely short validity period, which, together with theauthentication implied by the fact that the server knows how to locatethe customer, gives high security to the password. The mobile telephonenumber of the user uniquely determines the user so the mobile telephonemust be stolen, borrowed or cloned for identification to fail, unlessthe SMS message is intercepted by someone who can at the same time makeuse of this information, which is relatively hard as the authenticationchannel is independent of the communication channel.

This embodiment allows the user 102 to make use of their digitalsignature, while ensuring that the digital signature itself never leavesthe secure central certifying apparatus, whether encrypted, or not.

The distribution of password-tokens according to an embodiment of thepresent invention will now be described using the elements shown inFIG. 1. First, the user 102 contacts the signature server 110 from theworkstation 101 via channel 152. The signature server 110, via thesecure link 150 established between signature server 110 andauthentication server 120, then instructs the authentication server 120to send out a one-time password to the user 102. The authenticationserver 120 does this using SMS messaging, as described above, on channel151. The authentication server 120 also provides the signature server110 with a derived version of the one-time password, via channel 150.This derived version is, in this embodiment, a hash value of theone-time password. The hash value is derived using a standard one wayalgorithm, such as SHA-1 (see Secure Hash Standard; FIPS Pub 180-1,1995, National Institute of Standards & Technology, USA, the contents ofwhich are incorporated herein by reference). A hash value is typicallymuch smaller than the message from which it is so derived and, once thehash is calculated, the original message cannot be found from it. It isalso very unlikely that two messages would have the same hash value.This hash of the one-time password is then compared with the hashsupplied by the workstation 101. Since the same standard hashingalgorithm is used by both the authentication server 120 and theworkstation 101, if the two hashes match then the user is accepted asbeing authenticated by the signature server 110. Alternatively, anothertype of derived version of the password can be sent to the signatureserver 110. The requirement is only that the process used to derive theversion of the password or token-response is the same in theauthentication server 120 and workstation 101 so that a password willgive the same derived version as authentication server 120 andworkstation 101 but two different passwords will not give the sameresult.

The comparison of hash values allows the user to be verified while thesignature server 110 never receives the actual one-time password.

A variation to the distribution of password tokens described above willnow be described. The user establishes independent connections to boththe signature server 110 and the authentication server 120, rather thanonly to the signature server 110. In this instance the data to becertified is sent to the authentication server 120 through one interfaceand a hash value of the data to the signature server 110 through anotherinterface. Alternatively, the hash value could be replaced by, or addedto with, other related data. Typically, the data to be certified isgenerated at the source device on the basis of third party applications(e.g. a bank) through e.g. an applet or applets, which then forwards thedata and a hash on the data to the authentication server 120 andsignature server 110 respectively. Each connection may be authenticatedby use of a separate token, e.g. a fixed password for the signatureserver connection and a one-time password for the authentication serverconnection. The authentication server 120 forwards the data to becertified to the signature server 110, which may compute a hash of thedata and compare this with the hash received directly from the user 102.This scheme also provides strong assurance at the signature server 110that the user 102 has been authenticated by the authentication server120, but has the advantage that no information relating authenticationserver user authentication is received by or available to the signatureserver 110.

The signature server 110 is supported by a tamper-resistant hardwaresecurity module (HSM) which has a protected cryptographic facility suchas the IBM 4758, where keys and signatures are generated, and if keysare not in use then they are stored externally, encrypted under a masterkey. As shown in FIG. 2, in an embodiment of the invention, initial dataprovided by the workstation 101 to the certifying appends is transferredto the HSM 111 via a channel 141 set up using the password of the user102 and standard encryption techniques. A second layer of encryption 140extends from the workstation to the certifying apparatus, but does notextend into the HSM 111. This is a strong encrypted link with theauthentication of the server, and this channel carries furtherinformation regarding details of the user 102 and specifying theauthentication method to be used for the alternate channel 151. The mainpoint is that no sensitive key ever appears in the clear outside thesecure box. Such solutions are widely used by e.g. the bankingenvironment, e.g. in connection with pincode-protection. The database112 records all information regarding administrators. The HSM 111handles storage of keys and cryptographic functionality. The signatureserver 110 is protected both by a firewall 180 and by physical security182 to prevent, reduce or deter unauthorised access.

In an embodiment of the invention, the signature server 110 is supportedby clients 160, 161, 162 operated by trusted personnel e.g. under dualcontrol, connected by an authenticated and encrypted link to thesignature server 110. During a session between signature server 110 andclient, the administrator will first log on, and at this stage sessionkeys to authenticate and encrypt all communication between the client160, 161, 162 and the signature server 110 is agreed using the masterkey, again using standard procedures for setting up a VPN between theclient 160, 161, 162 and the server. The necessary transport keys(master keys for exchange of session keys) are stored on smartcards, areoperated by administrators and are used to administer (i.e.create/enable/disable) security officer and clerk accounts for thesignature server 110, to browse the data in the signature server's 110database and to register customers (those who have a signature on theserver) on the signature server 110.

In highly secure transactions, an embodiment of the invention offersfurther enhancement, to thwart attacks launched through the graphicaluser interface to achieve what is known as WYSIWYS (What You See Is WhatYou Sign)); One simple possibility is to let the certifying apparatusconfirm essential parts of the data supplied by the user forcertification via the second channel used for authentication purposebefore the certification is carried out. In this instance the wholemessage to be certified has to be forwarded to the certifying apparatusfor inspection.

The security of officers and the clerks are two levels of administratorof the signature server 110: the security officer is responsible for allsecurity related aspects of operating the signature server 110,including adding new administrators, exporting the audit log, andsuspending or disabling administrator accounts. The clerk is responsiblefor user related activities such as registering new customers with thesystem, suspending/disabling customers, extracting reports about thecustomer activities and the like. The two levels give increased securityto the system by restricting access to some systems more than others.

While two levels of signature server 110 administrators have been given,it is possible to divide authorised activities between any number ofdifferent structures as required. For example, it is possible to allowthe customer to perform simple administrative tasks such as issuing newpasswords, requesting reports on their activity or suspending his ownaccount if fraudulent use is suspected. However, in the presentembodiment accounts can only be reenabled by a clerk and will result ina new password being sent from the authentication server 120 to thecustomer via the user's mobile telephone.

The authentication server 120 is also enhanced by a hardware securitymodule 121, and has a database 122, in the same way as the signatureserver 110 and protected by a firewall 181 and physical security 183.The authentication server 120 is also connected with clients 170, 171,172 using authenticated encrypted channels as described above inrelation to the signature server 110 client links. For security, theseclients 170, 171, 172 are separate to the clients 160, 161, 162administering the signature server 110.

The signature server 110 and authentication server 120 is preferablyhoused geographically separated and are each operated by an independentbody with separate clients 160, 161, 162 and 170, 171, 172 administeringeach. This reduces the possibility that there will be unauthorisedaccess to both servers, which would be required if the private key ofthe user were to be misused.

Alternatively, the authentication server 120 and signature server 110may be housed in the same certifying apparatus. In such a case theadministration clients 160, 161, 162, and 170, 171, 172 for each server(e.g. the interface through which the server is operated) shouldpreferably remain separate, so that increased security is provided, byensuring that access to both servers cannot be obtained through the sameclient, although they could be the same. The advantage of thissingle-sever approach is that this approach is simpler, as only oneserver is operated rather than two, but the disadvantage is that morecare is required to assure that the trusted personnel cannot thwart thesystem in any way.

As well as the on-line one-time password given so far in the presentembodiment, a number of other types of password and delivery methods maybe employed in addition to SMS messages distributing on-line one-timepasswords. Authentication may be achieved by means of tokens 190 e.g.passwords, one-time passwords, stored secrets etc. The different typesof token have different properties regarding their mobility andsecurity. For all types of password a key is generated forauthenticating the request at the signature server 110. The signatureserver 110 will generate the key in a similar way and verify therequest.

Fixed passwords are passwords which do not change, and can be used manytimes on different occasions to authenticate a user. Such fixedpasswords are mobile, but less secure than one-time passwords becausethey are easily eavesdropped, either by physically observing thecustomer when the password is entered, or by fooling the customer intoentering the password in a false password prompt. It is not possible todetermine whether a fixed password is compromised or not, but in case ofsuspected compromise (e.g. based on audit trails), the password can bedisabled.

Fixed passwords must originally be provided by the authentication server120, to the user, via a secure channel (e.g. in a sealed envelope)because initially the user has no way of authenticating himself on thenetwork. After the initial password has been received, the user maychange the password online if sufficient authentication andconfidentiality is provided.

Fixed passwords may be categorised by how susceptible they are for beingcompromised, such that one may have one password for controlled orsecure environments and another for less controlled or secureenvironments.

Alternatively, stored one-time passwords may be employed, which aremobile and safer than fixed passwords, but may be compromised byphysical theft or by copying. Theft is easily detected whether thepasswords are stored on print or in a mobile device. However, copying isnot detectable.

Stored one-time passwords have a long validity period and must betransmitted securely from the authentication server 120 to the user. Thecopying of one time passwords must be prevented and this may be veryhard to do if passwords are transmitted on-line over the Internetbecause they may reside in various cache files, printer buffers etc.,for a long time after the user believes them to be erased.Cryptographically secured communication reduces the problem of obtainingthe passwords during transmission to the user, but does not guaranteeanything about plain text copies stored at the workstation.

The on-line one-time passwords of the present embodiment are more securethan stored one-time passwords due to the short validity period makingtheft and subsequent use virtually impossible. However, interception ofthe alternate channel is still possible, although it is highly unlikelythat both channels may be attacked by the same attacker at the sametime, which is a strength of the approach.

A further alternative is a terminal fingerprint, which may be used toidentify a particular user's workstation 101. It is a value thatuniquely identifies the workstation 101. Such a fingerprint can becomputed based on secrets stored on the workstation 101, the hardwareconfiguration of the workstation 101 and all serial numbers of hardwaredevices in the workstation 101. However, as a fingerprint can be forgedby copying all this information, fingerprints are only relevant forterminals in controlled environments i.e. those having physical andsoftware protection. Terminal fingerprints are not suitable tokens in asituation where the customer uses many different terminals, but ratherfor the situation where trustworthy identification is required for asingle terminal. Stealing a fingerprint requires a break-in or a hackerattack, but cannot be considered detectable.

It would improve the security, if there is one secure trustedworkstation 101 available to the user with a secure tunnel connection tothe signature server 110 as well as the authentication server 120, inthat this would enable the user e.g. to change his memorised password ina secure manner at any point in time from this particular work station.

In a further alternative, a high level of security occurs when sessionswith the signature server 110 are chained. This means that the serverreturns a token 190, which is stored on the workstation 101 and returnedto the server on instigation of the next session. The token 190 returnedmay or may not be distributed and kept securely but will always allowthe customer to detect abuse of his signature, since the next sessionwill fail authentication because the token will have been returned tothe fraudulent user, rather than the legitimate one. This solutionrequires careful synchronisation between customer and server in order toensure that tokens are not lost in case connections fail. There are manyknown and well understood methods for dealing with this.

A further, more secure token 190 is a cryptographic add-on for acomputer, which allows complete identification of a workstation 101 bythe use of a challenge-response protocol. Although such add-ons may bephysically small and flexible, they are not suited to use with multipleworkstations 101 as their complete identification of a singleworkstation 101 is required An example of this would be a small unit(“dongle”) connected to the serial port of the workstation 101, such asdevices available on the market for software and or informationprotection.

Handheld devices such as password generators and smart card front endsallow very trustworthy identification of the device in question, eventhough the device may be stolen just as any other device. Compared withterminal one-time passwords via SMS to another telephone, the advantageof a handheld cryptographic device is that the SMS message may beeavesdropped or intercepted, whereas the cryptographic device may not bemeaningfully so.

The most secure means of identification may be the use of a physicalattribute of the user such as a retinal or fingerprint scan. However, atthe present time, such scanners are not widely available on anyworkstation 101 through which a session may wish to be conducted.

As communication with mobile units becomes more advanced, it will bepossible to adapt more and more advanced authentication channels, andthese could equally be used, as long as they fulfil the requirements ofuser authorisation and/or authentication.

Obviously, various schemes discussed above will have various levels ofsecurity. The lowest level (level 1) is where the user just memorises apassword he shares with the signature server, which he includes whenevera signature must be generated.

More advanced is the solution (level 2) where in addition he includes aone-time password which he has received previously via an independentauthorised channel from the authentication server, e.g. an SMS message,a paper based list by ordinary mail, or communicated to a secure workstation through an encrypted tunnel and then printed out. At every newtransaction, a new password is used in addition to a unique passwordmemorised by the user.

Even more advanced and flexible (level 3) is the situation where theuser possesses a handheld token, such as a VASCO Digipass, or the RSASecureID Key Fob, which shares e.g. conventional key with the signatureserver. When the user logs on, he either receives a so-called challengefrom the certification device which he keys in on the token. The tokenthen processes the challenge and returns a so-called response on itsdisplay, which is keyed in on the work station by the user as the onetime password, and verified to be correct by the certification device.Other tokens, generally available on the market as well, automaticallycalculate a new response at regular intervals using a key shared withthe certification device, which may be varied without the use of achallenge, as the challenge is implicit to the system.

For level 3, any sufficiently secure personal identification schemebased on tokens available on the market may in principle be incorporatedinto the invention in order to create the necessary authentication ofthe user. This token may also be a mobile device, which may communicatesecurely with the certification device e.g. using WAP-security for thereceipt of one-time passwords from the authentication server, orwhichever communication security is available for that device, such asBluetooth or infrared carried communication to some terminal connectedto the authentication server trough a physical network. Again thephysical network need not be secure, as the communication is secured bymeans of a secure tunnel between the authentication server and themobile device.

A further level of security, for example for a fixed permanent trustedworkstation 101 may be reached if a hardware cryptographic device isused to provide complete identification of the workstation 101. For thislevel the workstation 101 could be bound to an IP-address or to atelephone number.

Of course, many levels of access and security can be introduced asrequired with different properties and requirements. Advantages of theabove embodiments are that the signature server 110 is used in such away that the private key of a user is never transmitted outside of thesecure signature server 110, whether or not encrypted. This means thatsubstantially increased security is available protecting the privatekeys of users.

Because it is possible to operate with different trust levels, dependingon the authentication token 190 or tokens supplied to the signatureserver 110, poorly identified sessions (i.e. those authenticatedaccording to level 2) may be used for only signatures for transactionswith small potential losses as a result of fraud (e.g. small banktransactions) whereas a more secure session (i.e. those authenticatedaccording to level 3 or 4) such as the user's home PC, may be used fortransactions with larger potential losses as a result of fraud, theembodiments of the present invention allow the combination of use of asecure fixed terminal system together with the mobility given by beingable to use any workstation 101. Therefore the advantages of each aregiven.

When a customer wishes to be registered at the signature server 110, heor she contacts a clerk, who takes care of the registration. If thecustomer wishes to be registered with a certificate, two options existdepending on whether the CA and the signature server 110 are operated bythe same organisation or not.

1. If both servers are operated by the same organization, the client canbe registered at the CA and at the signature server 110 simultaneously,and a key pair and a certificate can be generated immediately.

2. If the servers are operated by different organisations, the customerfirst needs to be registered at the CA and perhaps receive a sender keyID and an IAK (Initial Authentication Key) then the customer can just beregistered at the signature server 110. If the customer is willing toreveal the sender ID and the IAK to the clerk, the key pair can begenerated immediately as in case 1, otherwise the key generation must beinitiated via the internet.

The registration procedure can be achieved using well known andunderstood methods, such as the International Standard PKIX, and wouldtypically be the responsibility of the chosen CA. Certificates wouldonly be required when the certifying apparatus is receiving data to becertified from many source devices. If the source device is known thenno external CA would be required.

FIG. 3 shows a flow diagram of the steps involved when a message issigned with the user's private key held on the signature server 110.

At S300 the message is entered onto a workstation 101. The message maybe manually entered at the workstation 101. Alternatively, the messagemay be written at an earlier stage and stored elsewhere before beingloaded onto the workstation 101. When the message is ready to be sent,in this embodiment the workstation 101 is connected to the Internet.However, direct (point to point) connection between workstation andsignature server 110 may alternatively be used. The Internet is used tocontact the signature server 110 over an insecure channel. At thisstage, the signature server 110 and workstation 101 do not know to whomthey are respectively connected. In order to determine this,verification of the communications is required at S302. Verification ofthe signature server 110 can be accomplished by the use of a publickey/private key pair. The signature server's 110 public key is publishedand available to the workstation 101, for instance, from a CA. Variousmethods of establishing the identity of the server are then availablethat all involve the use of the server's private key to encrypt ordecrypt a message. Since the private key of the signature server 110 isknown only to the signature server 110, the workstation 101 is able toidentify messages as coming from the signature server 110. Also, usingthe signature server's 110 private key/public key pair, a secure tunnelis able to be set up from the workstation 101 to the signature server110 by the workstation 101 encoding with the server's public key andonly the server being able to decrypt it with its private key. A widevariety of authentication and encryption processes, which are well knownin the art, can be employed in the invention. In the present embodiment,the user is identified by use of a fixed password which is recognised bythe signature server during the authentication process.

However, at this stage, the signature server 110 has not authenticatedthe workstation 101 as being used by a particular user of thecertification system. The signature server 110 needs to receive somesecret from the workstation 101 which is only known by the user in orderto carry out authentication. This is done by the signature server 110requesting that the authentication server 120 send an on-line onetimepassword to the user over a separate channel to the link between thesignature server 110 and the workstation 110 at S304. In thisembodiment, this is done by an SMS message. The user subsequently entersit into the workstation 101 at S308, once it has been received. Becausethe connection from workstation 101 to signature server 110 is secure inthe direction from workstation 101 to signature server 110,eavesdropping will not identify the password entered and sent to thesignature server 110. In addition, as stated above, the workstation 101derives a hash value from the password, rather than sending the passwordover the connection at S310. The authentication server 120 sends its ownversion of the derived result to the signature server 110 at S312, andthe signature server 110 compares both values. If they are the same thenit is very unlikely that an incorrect password was entered and thepassword is verified at S314.

Once the password has been verified, a bi-directional secure channel isestablished at S316. This can be set up by using the secret (i.e. thepassword), which is sent to the signature server 110 with the signatureserver's 110 public key to generate a session key. This secure channelis based on the usual principles of a VPN.

Alternatively, one of the other forms of password or token 190 discussedabove may be used to authenticate the user depending on whether the useris at a secure workstation 101 or a non secure workstation 101.

As mentioned, the invention is not limited to any specific algorithmsand methods to set up the security channel. The requirement is simplythat a secure channel is established In the case of the currentembodiment, the secure channel is bi directional, However, this need notbe the case in general.

Once the bi-directional secure channel has been established, theworkstation 101 calculates a hash value of the message which the userwishes to be certified at S318. This hash value is then sent over thesecure channel, to the signature server 110. Once the signature server110 receives the hash value, it retrieves the private key of the userfrom the HSM and encodes the hash value with the user's private key atS320 (of course, the user's private key may be retrieved at any timeafter the user's identity is established).

The signed hash is then returned to the workstation 101. This hash hasnow been encrypted using the private key of the user and so is certifiedas originating from that user. This has been achieved without theprivate key ever leaving a physically and software protected environmentof the signature server 110. Therefore, this embodiment of the inventionovercomes the security disadvantages by ensuring that the private key isnever available outside the signature server 110. This increase insecurity of the private key results in an increased value of thecertificate, as the message is more likely to be authentic.

The signed hash value is then embedded in the full original message atS322 and can then be sent over an insecure channel, such as theInternet, to a recipient S324. The message is certified as being fromthe owner of the digital signature.

Additionally, because in an embodiment of the invention the signatureserver 110 and the authentication server 120 are both used, and arepreferably separated geographically, and because all tree of workstation101, signature server 110 and authentication server 120 must be involvedin the certifying of the data from the workstation 101, both thesignature server and authentication server must be compromised in orderto falsify a certification. The likelihood of this is reduced by theseparation of the servers, and by independent administration of eachserver.

An insecure channel may be used to distribute the signed message, sincethe signed hash value acts both as an identifier and an authenticator ofthe message content. At S326 in FIG. 3, the recipient checks with thecertification authority used to issue the user's public key/private keypair, and receives the user's public key. This is used to decrypt thehash value of the message and so certify that the originator of themessage is the user. In addition, the recipient can calculate the hashvalue of the message itself and check that this hash value matches theencrypted hash value. If this is not the case, then the message has beentampered with and can be discarded.

If the message is sent over an insecure channel, while it will not bepossible to tamper with the message without detection, it still may bepossible to intercept and read the message before it is received by therecipient. In order to avoid this, a secure channel between user andrecipient can be established using a method as described above, or anyother suitable method. The secure channel need only be from the user tothe recipients. The recipients need not establish a secure channel forinformation passing back to the user, unless sensitive or secretinformation is to be returned to the user from the recipient.

Alternatively, in order to avoid the problem of third partiesintercepting and reading the message between user and recipient, amethod as shown in FIG. 4 may be employed.

This method is similar to that shown in FIG. 3. In S400 the message isentered into the workstation 101. S402 to S416 are as described abovewith reference to FIG. 3, to establish a secure channel betweenworkstation 101 and signature server 110. However, only a one-way securechannel need be established because, in this embodiment, the stepsfollowing establishment of a secure channel are different to theembodiment shown in FIG. 3. This embodiment differs in that the wholemessage is sent from the workstation 101 to the signature server 10 atS418.

Therefore, no information requiring encryption need be returned to theworkstation 101 from the signature server 110. However, in practice, abi-directional secure channel is preferably set up, to avoidmisinformation from third parties regarding the signature server 110,and its status, being sent to the workstation 101.

In this embodiment, the signature server 110 uses the user's private keyto encrypt the entire message as sent by the user. In addition, the useralso supplies delivery details for the message to a recipient. At thisstage, other than a notice of receipt of the message, the signatureserver 110 need not reply to the workstation 101.

Once the message has been encrypted with the user's private key, thesignature server 110 also adds the signature server's 110 signature, byencrypting with the signature server's 110 private key, and forwardsthis encrypted message to the new recipient directly. The recipients canverify the message in the same way as discussed with relation to FIG. 3,except that the signature server's 110 public key is used, as well asthe user's public key. Again, standard methods for encryption andsigning are used here.

Some, or all signature requests can have a summary field which is loggedin the audit log. The purpose of the summary is to make it possible toextract meaningful reports over the customers' activities and allowtracing, if a transaction is questioned.

In addition, multiple request transactions may be supported wherein theuser supplies multiple requests for multiple signals where each requestmust be separately authenticated. This allows the customer to prepare anumber of requests and have them all executed with a single log-on. Ifnecessary, special network applications may cache passwords in order toprovide a more user-friendly interface.

The user can also request that a message or message hash is tie-stampedand have a limited life-spar. This is done using a flag in the signaturerequest which determines whether a time-stamp should be supplied or not.Time stamping could, for example, be supported by contacting a timestamp server via the PKIX TSP protocol, where a received signature onsome message, or the concatenation of a number of signatures is sent toan independent third party offering independent timestamping. Atimestamp is then added, and a signature is generated on the messageconsisting of the received signatures and the timestamp.

An alternative method to that described with reference to FIGS. 3 and 4above will be described with reference to FIG. 5.

The system and method is especially useful where the signature andauthentication servers 110, 120 are geographically separated andadministered by independent bodies. All other features may be as eitherdescribed with reference to FIGS. 3 and 4.

The data to be signed is entered on the workstation at S500. Anapplication or other program downloaded from a third party to theworkstation 101. In this embodiment, the workstation runs the applet orprogram, which connects to both the signature server 110 andauthentication server 120. The signature server 110 requests andreceives the fixed password from the user 102 (as described in regard toregistration above) at S502. An authorised connection with the signatureserver 110 is then established at S504 as described before withreference to S302 described above.

The signature server 110 then requests the authorisation server 120 tosend a one-time password to the user via a different channel at S506 asin S304 described above.

The one-time password is seat to the user at S508 who enters it acrossthe connection established between workstation 101 and authorisationserver 120 at S510. A verified connection is therefore set up betweenboth workstation 101 and signature server 110, and workstation 101 andauthentication server 120 at S512.

The data to be certified is sent to the authentication server 120through one connection at S514, and a derived value (in this embodimenta hash value of the data, as described above) of the data to becertified is sent to the signature server 110 at S516.

The authentication server 120 sends the data to be certified to thesignature server, which computes the hash of the data to produce aderived value for comparison with the derived value sent direct from theworkstation.

The two derived values are then compared by the signature server 110 atS518, which ensures that the two servers are connected to the same user.

The signature server 110 can then sign the data received from theauthentication server 120 and return it to the workstation 101, orforward to a third party recipient.

It is also possible that the derived version of the data be sent to theauthentication server 120 and the actual data sent to the signatureserver 110. However, this is not preferred as the signature server 110is then in possession of the data to be signed before the authenticationserver 120 authenticates it and the system could therefore be abused ifillegitimate control of the signature server 110 was obtained.

As well as using the one-time password issued by the authenticationserver 120 to authenticate the connection between the workstation 101and signature server 110, as described above, it is also possible to usea token to validate the connection between workstation 101 and signatureserver 110, in the case of FIG. 4, and separate tokens to validate theconnections between the workstation 101 and each server in the case ofFIG. 5. In this alternative validation procedure, the two channels areestablished completely independently, which is especially useful wherethe signature and authentication servers 110, 120 are separatedgeographically and administrated separately.

The embodiments provide a certification method which meets therequirements for adequate protection of the private key e.g. to meet therequirements in the Directive of the European Union on qualifiedcertificates; allows the genuine owner to initiate the generation of adigital signature from any appropriate workstation 101 connected to someappropriate network, such as the Internet, without ever compromising thesignature key, yet at the same time prevents anyone with total controlover a workstation 101 which has been used as described above tosubsequently have a new signature generated by means of the key of thatowner.

Although the above embodiments have been described in relation to aworkstation and server, any situation where a message needs to be signedwith a digital signature without the private key of a user leaving asecure server will also fall within this invention. Also, the termsserver, client and workstation used herein are not limited to the narrowmeaning of the terms. A server may be any computer or the like, whichcan be contacted as a central unit by a number of workstations. Aworkstation is in interface between the user and the server, whichtransmits the electronic data and passwords, if required, to the server.Clients are simply interfaces, which allow administration of a server.

The present invention has been described above purely by way of example,and modifications can be made within the spirit of the invention. Theinvention also consists in any individual features described or implicitherein or shown or implicit in the drawings or any combination of anysuch features or any generalisation of any such features or combination,which extends to equivalents thereof.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise”, “comprising”, and thelike, are to be construed in an inclusive as opposed to an exclusive orexhaustive sense; that is to say, in the sense of “including, but notlimited to”.

1. A method of certifying electronic data supplied by a user, the methodcomprising: receiving data supplied by the user to be certified at acertifying apparatus from a source device; sending a request to a remotedevice instructing the remote device to send a password to the userwherein the password is sent from the remote device direct to the userwithout the password being received at the certifying apparatus;receiving, at the certifying apparatus direct from the remote device, ahash value derived from the password; receiving, at the certifyingapparatus direct from the user, a further hash value derived from thepassword; comparing, at the certifying apparatus without receiving saidpassword, the further hash value from the user with the hash value fromthe remote device; validating the user if the further hash value fromthe user matches the hash value from the remote device; certifying thedata at the certifying apparatus with one or more elements ofinformation secure to the certifying apparatus, said elements beingunique to the user if the further hash value matches the hash valuederived from the remote device; and outputting the data so certifiedfrom the certifying apparatus, for passing to a recipient device;wherein the elements of secure information certify that the supplier ofthe data is the user.
 2. A method according to claim 1, wherein theprivate key of a public key/private key pair specific to the userdefines a said element unique to the user.
 3. A method according toclaim 1 or 2, wherein a digital signature specific to the user defines asaid element unique to the user.
 4. A method according to claim 1 or 2,wherein the recipient device is the source device.
 5. A method accordingto claim 1 or 2, wherein the recipient device is a third party device.6. A method according to claim 1 or 2, wherein a hash value of a messageto be certified is generated at the source device, the hash value beingthe data to be certified by the certifying apparatus.
 7. A methodaccording to claim 1 or 2, wherein the certifying apparatus can receivedata from many different source devices.
 8. A method according to claim1, further comprising authenticating a connection between said sourcedevice and said certifying apparatus using a fixed password recognizedby said certifying apparatus; and establishing a secure channel betweensaid source device and said certifying apparatus by using a said hashvalue received by said certifying apparatus together with a public keyof said certifying apparatus to generate a session key for said securechannel.
 9. A method according to claim 1, further comprisingestablishing an encrypted channel between said remote device and saidcertifying apparatus, wherein said certifying apparatus and said remotedevice include tamper resistant hardware, and wherein said encryptedchannel comprises a secure tunnel between said remote device and saidcertifying apparatus such that keys used for the tunnel are controlledby said tamper resistant hardware and do not appear in clear outsidesaid certifying apparatus.
 10. A method of certifying electronic datasupplied by a user, the method comprising: establishing a secureconnection between a source device operated by the user and a certifyingapparatus; sending data supplied by the user from the source device tobe received by the certifying apparatus; receiving at the source devicea password direct from a remote device without the password beingreceived at the certifying apparatus; sending a hash value of saidpassword from said source device direct to said certifying apparatus,with a further hash value of said password being received at saidcertifying apparatus direct from the remote device so that the furtherhash value from the remote device is compared by the certifyingapparatus with the hash value from the user to thereby validate the userif the further hash value matches the hash value without the certifyingapparatus receiving said password; and receiving at the source device aversion of the data from the certifying apparatus certified asoriginating from the user, using information unique to the user.
 11. Amethod according to claim 10, further comprising the step ofincorporating a certified version of the data into further data to besent to a third party device.
 12. A method according to claim 10 or 11,wherein the certifying apparatus holds information unique to the user tocarry out the certification.
 13. A method according to claim 12, whereinthe unique information is the private key of a public key/private keypair specific to the user.
 14. A method according to claim 12, whereinthe unique information is a digital signature specific to the user. 15.A method according to claim 10 or 11, wherein the data to be certifiedis a hash value of a message.
 16. A method according to claim 10,further comprising authenticating a connection between said sourcedevice and said certifying apparatus using a fixed password recognizedby said certifying apparatus; and establishing a secure channel betweensaid source device and said certifying apparatus by using said hashvalue together with a public key of said certifying apparatus togenerate a session key for said secure channel.
 17. A method accordingto claim 1 or 10, wherein the certifying apparatus comprises a signatureserver.
 18. A method according to claim 1 or 10, wherein the certifyingapparatus comprises a plurality of signature servers using secretsharing to store individual portions of a private key of a user, andwherein the signature is generated based on individual portions of aprivate key of a user stored on some or all of the signature servers.19. A method according to claim 17, wherein the certifying apparatusfurther comprises one or several authentication servers.
 20. A methodaccording to claim 1 or 10, wherein the source device comprises aworkstation.
 21. A method according to claim 1 or 10, wherein the sourcedevice comprises an interactive television.
 22. A method according toclaim 1 or 10, wherein the source device and certifying apparatusestablish authenticated individual connections between the source deviceand one or several servers of the certifying apparatus before and duringtransfer of the data to be certified.
 23. A method according to claim22, wherein the connection is encrypted.
 24. A method according to claim22, wherein the source device supplies a token to the certifyingapparatus for authentication.
 25. A method according to claim 24,wherein the token is supplied to the user or source device by thecertifying apparatus via an alternate channel to the authenticatedconnection.
 26. A method according to claim 25, wherein the alternatechannel is a mobile telephone network.
 27. A method according to claim26, wherein the token is distributed as a Short Message Service message.28. A method according to claim 24, wherein the token is a fixedpassword.
 29. A method according to claim 24, wherein the token is aone-time password.
 30. A method according to claim 24, wherein the tokenis unique to a transaction.
 31. A method according to claim 24, whereinthe token is stored on a portable device.
 32. A method according toclaim 24, wherein more than one type of token may authenticate the useror source device to one or several servers at the certifying apparatus.33. A method according to claim 22, wherein the method operates byauthenticating the user regardless of the source to provide a firstlevel of security, and operates by authenticating the user and sourcedevice to provide a second level of security.
 34. A method according toclaim 25, wherein the certifying apparatus certifies the data withdifferent unique elements, dependent upon the type of token used toauthenticate the user or source device.
 35. A method according to claim1 or 10, wherein validation data for validating the data to be certifiedis received from a remote device before the data is certified.
 36. Amethod according to claim 1 or 10, further comprising the certifyingapparatus sending the request to the remote device after receiving arequest to certify data.
 37. A method according to claim 20 furthercomprising establishing a communication channel between the workstationand the remote device.
 38. A method for use in data certification,comprising: receiving the data to be certified at a certifying apparatusfrom a source device; sending a request for user identification data toan authentication server via a secure tunnel from tamper resistanthardware of said certifying apparatus to tamper resistant hardware ofsaid authentication server, wherein said secure tunnel comprises anencrypted and authenticated communication link; and wherein said useridentification data request is sent in the form of a challenge from theauthentication device direct to a said user; receiving, at saidcertifying apparatus, a response to the user identification data requestwhich is an encryption of said challenge direct from said user andreceiving, at said certifying apparatus, a derived version of saidresponse via the secure tunnel direct from said authentication server;validating, at said certifying apparatus, the user if the response tothe user identification data request matches the derived version of saidresponse from the authentication server; certifying the electronic datasupplied by the user at the certifying apparatus with one or moreelements of information secure to the certifying apparatus, saidelements being unique to the user; and outputting the data so certifiedfrom the certifying apparatus, for passing to a recipient device;wherein the elements of secure information certify that the supplier ofthe data is the user.
 39. A method according to claim 38, wherein therequest and derived version of the identification are transferred via adifferent communication method to the identification data.
 40. Acomputer apparatus for use in data certification, the apparatuscomprising: a program memory storing instructions for controlling aprocessor; and a processor for reading and implementing the instructionsstored in the program memory; wherein the program instructions stored inthe program memory comprise instructions for controlling the processorto carry out the following steps: receiving data supplied by the user tobe certified at a certifying apparatus from a source device; sending arequest to a remote device instructing the remote device to send apassword to the user wherein the password is sent from the remote devicedirect to the user without the password being received at the certifyingapparatus; receiving, at the certifying apparatus direct from the remotedevice, a hash value derived from the password; receiving, at thecertifying apparatus direct from the user, a further hash value derivedfrom the password; comparing, at the certifying apparatus withoutreceiving said password, the further hash value from the user with thehash value from the remote device; validating the user if the furtherhash value from the user matches the hash value from the remote device;certifying the data at the certifying apparatus with one or moreelements of information secure to the certifying apparatus, saidelements being unique to the user if the further hash value matches thehash value derived from the remote device; and outputting the data socertified from the certifying apparatus, for passing to a recipientdevice; wherein the elements of secure information certify that thesupplier of the data is the user.
 41. A computer apparatus forcertifying data as originating from a user, the apparatus comprising: aprogram memory storing instructions for controlling a processor; and aprocessor for reading and implementing the instructions stored in theprogram memory; wherein the program instructions stored in the programmemory comprise instructions for controlling the processor to carry outthe following steps: receiving the data to be certified at a certifyingapparatus from a source device; sending a request for useridentification data to an authentication server via a secure tunnel fromtamper resistant hardware of said certifying apparatus to tamperresistant hardware of said authentication server, wherein said securetunnel comprises an encrypted and authenticated communication link; andwherein said user identification data request is sent in the form of achallenge from the authentication device direct to a said user;receiving, at said certifying apparatus, a response to the useridentification data request which is an encryption of said challengedirect from said user and receiving, at said certifying apparatus, aderived version of said response via the secure tunnel direct from saidauthentication server; validating, at said certifying apparatus, theuser if the response to the user identification data request matches thederived version of said response from the authentication server;certifying the electronic data supplied by the user at the certifyingapparatus with one or more elements of information secure to thecertifying apparatus, said elements being unique to the user; andoutputting the data so certified from the certifying apparatus, forpassing to a recipient device; wherein the elements of secureinformation certify that the supplier of the data is the user.
 42. Adata certifying apparatus, comprising: a signing device adapted tocertify electronic data received from a remote source device asoriginating from a user, wherein the certifying apparatus is arranged toreceive data from the source device, certify the data as belonging tothe user, using information stored in the certifying apparatus andcryptographic techniques, said information being unique to the user, andsend the certified data to a recipient device and wherein the certifyingapparatus is arranged to send a request to a further remote deviceinstructing the further remote device to send a password direct to theuser without the password being received at the certifying apparatus;receive a hash value derived from the password direct from the furtherremote device; receive a further hash value derived from the passworddirect from the user; compare, without receiving said password, thefurther hash value from the user with the hash value from the furtherremote device; validate the user if the further hash value from the usermatches the hash value from the remote device; and certify the data tobe certified if the further hash value from the user data matches thehash value from the further remote device.
 43. A certifying apparatusaccording to claim 42, wherein the recipient device is the sourcedevice.
 44. A certifying apparatus according to claim 42, wherein therecipient device is a third party device.
 45. A data certifyingapparatus according to claim 42 or 43, wherein the source device andcertifying apparatus are arranged to establish an authenticatedconnection between them before and during transfer of the data to becertified.
 46. A data certifying apparatus according to claim 45,wherein the source device and certifying apparatus are arranged suchthat the connection between them is encrypted.
 47. A data certifyingapparatus according to claim 45, wherein the source device is arrangedto supply a token to the certifying apparatus for authentication.
 48. Adata certifying apparatus according to claim 47, wherein theauthentication device is arranged to supply the token to the user orsource via an alternate channel to the authenticated connection.
 49. Adata certifying apparatus according to claim 47, wherein the token is afixed password.
 50. A data certifying apparatus according to claim 47,wherein the token is a one-time password.
 51. A data certifyingapparatus according to claim 47, wherein the authentication device isarranged to supply the token to the user or source device via a mobiletelephone network.
 52. A data certifying apparatus according to claim50, wherein the authentication device is arranged to supply the token tothe user or source device via a Short Message Service message.
 53. Adata certifying apparatus according to claim 47, wherein authenticationdevice is arranged to supply a unique token for each transaction.
 54. Adata certifying apparatus according to claim 47, wherein the token isstored on a portable device.
 55. A data certifying apparatus accordingto claim 47, wherein the certifying apparatus is arranged to use morethan one type of token to authenticate the user or source device.
 56. Adata certifying apparatus according to claim 55, wherein the datacertifying apparatus is arranged to operate by authenticating the userregardless of the source device to provide a first level of security andto operate by authenticating the user and the source device to provide asecond level of security higher than the first level of security. 57.The data certifying apparatus according to claim 47, wherein thecertifying apparatus is arranged to certify the data with differentunique elements, dependent upon the type of token used to authenticatethe user or source device.
 58. A data certifying apparatus according toclaim 42 or 43, wherein the certifying apparatus comprises a signatureserver.
 59. A data certifying apparatus according to claim 58, whereinthe certifying apparatus comprises a plurality of signature servers,each signature server being arranged to use secret sharing to storeindividual shares of a private key of a user, wherein, the signaturegenerated.
 60. A data certifying apparatus according to claim 58,wherein the certifying apparatus further comprises an authenticationserver.
 61. A data certifying apparatus according to claim 42 or 43,wherein the source device comprises a workstation.
 62. A data certifyingapparatus according to claim 42 or 43, wherein the source devicecomprises an interactive television.
 63. Apparatus according to claim42, further adapted to authenticate a connection between said sourcedevice and said certifying apparatus using a fixed password recognizedby said certifying apparatus; to establish a secure channel between saidsource device and said certifying apparatus by using said hash valuereceived by said certifying apparatus together with a public key of saidcertifying apparatus to generate a session key for said secure channel.64. Apparatus according to claim 42, further adapted to establish anencrypted channel between said remote device and said certifyingapparatus, wherein said certifying apparatus and said remote deviceinclude tamper resistant hardware, and wherein said encrypted channelcomprises a secure tunnel between said remote device and said certifyingapparatus such that keys used for the tunnel are controlled by saidtamper resistant hardware and do not appear in clear outside saidcertifying apparatus.
 65. An apparatus for use in data certification,comprising: data certifying apparatus, the data certifying apparatuscomprising a signing device adapted to certify electronic data receivedfrom a remote source device as originating from a user, wherein thecertifying apparatus is arranged to receive data from the source device,certify the data as belonging to the user, using information stored inthe certifying apparatus and cryptographic techniques, said informationbeing unique to the user, and send the certified data to a recipientdevice; and an authentication server, said authentication server andsaid data certifying apparatus each having tamper resistant hardware,said tamper resistant hardware of said authentication server and saidtamper resistant hardware of said data certifying apparatus beingconnected by a secure tunnel, wherein said secure tunnel comprises anencrypted and authenticated communications link; and wherein said datacertifying apparatus is configured to send a request for userauthentication to said authentication server via said secure tunnel;said authentication server is configured to receive said request fromsaid data certifying apparatus via said secure tunnel and to supply saiduser with a user identification data request in the form of a challenge;said data certifying apparatus is configured to receive a response whichis an encryption of said challenge direct from said user; and saidauthentication server is configured to supply a derived version of saidresponse to the data certifying apparatus via said secure tunnel wherebysaid data certifying apparatus validates said user if the response tothe user identification data request matches the derived version of saidresponse.
 66. An apparatus according to claim 65, wherein the receivingmeans and further supplying means are arranged to operate via adifferent communication method to the supplying means.
 67. A method ofcertifying electronic data supplied by a user, the method comprising:establishing a secure connection between a source device and acertifying apparatus comprising a signature server storing a private keyspecific to the user and an authentication server; sending the data fromthe source device to be received by the certifying apparatus; receivinga password from a token device which shares an individual key with theauthentication server; sending a hash value of said password to saidcertifying apparatus for verification of the user by said certifyingapparatus; and receiving at the source device a version of the data fromthe certifying apparatus certified as originating from the user bydigitally signing at the signature server with the user's private key onbehalf of the user without the user's private key being transmitted fromthe signature server.
 68. A computer apparatus for use in datacertification, the apparatus comprising: a program memory storinginstructions for controlling a processor; and a processor for readingand implementing the instructions stored in the program memory; whereinthe program instructions stored in the program memory compriseinstructions for controlling the processor to carry out the followingsteps: establishing a secure connection between a source device operatedby the user and a certifying apparatus; sending data supplied by theuser from the source device to be received by the certifying apparatus;receiving at the source device a password direct from a remote devicewithout the password being received at the certifying apparatus; sendinga hash value of said password from said source device direct to saidcertifying apparatus, with a further hash value of said password beingreceived at said certifying apparatus direct from the remote device sothat the further hash value from the remote device is compared by thecertifying apparatus with the hash value from the user to therebyvalidate the user if the further hash value matches the hash valuewithout the certifying apparatus receiving said password; and receivingat the source device a version of the data from the certifying apparatuscertified as originating from the user, using information unique to theuser.